[レポート] DEV319 Continuous Integration ベストプラクティス #reinvent

[レポート] DEV319 Continuous Integration ベストプラクティス #reinvent

re:Invent2018 で行われたDEV319 Continuous Integration Best Practicesのレポートです。
Clock Icon2018.11.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事はAWS re:Invent 2018のセッション「DEV319 Continuous Integration Best Practices」 のレポートです。

セッション概要

Today, more teams are adopting continuous integration (CI) techniques to enable collaboration, increase agility, and deliver a high-quality product faster. Cloud-based development tools such as AWS CodeCommit and AWS CodeBuild can enable teams to easily adopt CI practices without the need to manage infrastructure. In this session, we showcase best practices for code reviews and continuous integration, drawing on practices used by Amazon engineering teams. We’ll incorporate demos to not just explain the practices but show you how.

スピーカーは以下のお二人。

  • Joseph Vusich - Software Development Engineer
  • Nick Brandaleone - Senior Solutions Architect, AWS

レポート

  • なぜContinuous Integrationが重要なのか?
    • Find bugs earlier
    • Fix bugs faster
    • Deliver faster
    • Deliver more often
    • Unblock developers
    • Grow developers
  • Continuous Integration Tools
    • Source Code
    • AWS CodeCommit
    • GitHub
    • GitHub Enterprise
    • Bitbucket
    • S3
    • Build & Test
    • AWS CodeBuild
    • Jenkins w/ CodeBuild
    • Glue
    • Amazon CloudWatch Events
    • AWS Lambda
      • slack integration
      • SNS (E-mail / Texts)
      • Any AWS Service
  • AWS CodeCommitの紹介
    • フルマネージドGitサービス
    • プラベートGitレポジトリ
    • S3バックエンド
    • スケールが容易
    • Store anything, anytime
  • AWS CodeBuildの紹介
    • フルマネージドBuildサービス
    • 継続的なスケーリング
    • Pay as you go
    • 拡張性
  • AWS CodeBuildの機能
    • ビルドソースはCodeCommit、S3、Bitbucket、GitHub/GitHub Enterprise
    • Webhookサポート
    • Multiple input repos and output artifacts
    • VPC内に配置
    • Amazon Parameter Storeを使える
    • S3 Build Cache
    • CodeBuild Agentを用いたローカルデバッグ

ここからContinuous Integration Journeyの話。
3パターンのビルドタイミング。

  1. Nightly checks
  2. Branch checks
  3. Pull request checks

Nightly checks

CloudWatch Event Scheduleによるトリガー。
Implement 毎晩ビルドを実行
Feedback loop 16-24時間
Team impact 間違えたコードを書くと翌日のビルドまでの期間、チームを止めることになる
Speed boosts Automate codebase maintenance; Email notification

Branch checks

Branchをチェック、コードがPushされたらビルドを実行。
Implement Pushごとにビルドを実行
Feedback loop コードがビルドされるまでの時間(小さい)
Team impact 短いサイクル、間違えたコードが修正されるまでチームを止める
Speed boosts slack notification; build badges, caching

Pull request checks

PRをチェック、PRをトリガーにビルドを実行。
Implement コードレビュー中にビルド
Feedback loop コードがビルドされるまでの時間
Team impact 間違えたコードでもチームを止めない
Speed boosts Integration tests; parallel builds

最後に

ベストプラクティスに則ってAWSサービスを使うことが
最も効率よく利益が最大になる利用方法だと思っています。
これからContinuous Integrationを導入していこうという
AWSユーザー方々の助けになれば幸いです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.